IBIS Macromodel Task Group

Meeting date: 25 January 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                            * Majid Ahadi Dolatsara
                            * Ming Yan
                              Radek Biernacki
                            * Rui Yang
                              Todd Bermensolo
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Arpad to Submit the Alphanumeric Pins BIRD draft to the Open Forum.
  - Done.
  
- Arpad to Submit the Clocked Rx AMI Models BIRD draft to the Open Forum.
  - Done.
  
- Michael Mirmak to send his AMI [Test Data] presentation to the ATM list.
  - Done.
  
- Fangyi to review Walter's draft of BIRD 211.4.
  - In progress.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the January 18th
meeting.  Michael moved to approve the minutes.   Lance seconded the motion.
There were no objections.

-------------
New Discussion:

Arpad's new Repeater_Type Value question email:
Arpad noted that he had recently come across an AMI model that contained a Model
Specific parameter that allowed the user to switch the mode of operation between
redriver and retimer.  However, the model also included the Repeater_Type
Reserved Parameter, which contained the value "Redriver".  Arpad said this could
be problematic, since the tool should do different things depending on whether
the model is a Redriver or a Retimer.

Arpad asked why the Repeater_Type was defined as having only a single value.
Why do we not allow the Repeater_Type to have Format List and allow Redriver or
Retimer to be selected?  Should we make this possible?  Is there a reason for
not allowing it?

Walter had replied to the email stating that he thought they would be two
fundamentally different models.  The model maker should use a [Model Selector]
and two separate [Model]s.  He didn't think we needed to complicate EDA tools
to deal with this scenario, and he noted that an .ami file supporting both
would likely have some parameters that only applied to the Redriver and others
that only applied to Retimer, and this would be confusing.  Arpad said a [Model
Selector] approach forced the model maker to duplicate the entire [Model] just
to provide a different [Algorithmic Model] section.  Ambrish said he saw no
harm in allowing the List.  He said AMI models are just software and the
parameter could select the mode.

Michael asked if the device could change modes on the fly.  He said that things
that are hard to do in hardware are usually similarly hard to do in modeling.
He said it's hard to create something that can be a redriver or retimer and
switch between them.  Changing the Repeater_Type parameter to allow a List for
selection would imply that this is something the user could do on a whim.

Fangyi agreed with Walter and Michael that it was unlikely that hardware could
switch modes in real time.  He agreed with Walter that a combined AMI file with
DFE and CTLE parameters, each of which applied to only one of the modes, would
make the model operation complicated and confusing.  For example, if the user
wanted to sweep the Redriver CTLE settings, they would also see DFE and other
Retimer-only settings.  Randy agreed that, as a model user, he would want
entirely separate .ami files.  He said it would be very confusing to have both
combined into one .ami file.  Arpad asked if Dependent (Dep) parameters could be
used to clarify the situation.  Fangyi said no.

Michael asked whether the concept of an "AMI Selector" would help, if Arpad was
concerned about duplicating the entire [Model] to use the [Model Selector]
approach.  Arpad asked whether anyone else in the group thought we needed to do
anything to change the Repeater_Type parameter definition.  No one responded.
No change is planned at this time.

Power Supply Induced Jitter (PSIJ) Modeling in IBIS:
Randy reported that his discussions with the MS&T team have continued.  He said
he had been reviewing some NGSPICE code and looking at their algorithms.  He
will be doing more testing.

GDDR6X:
Walter said they had implemented support for GDDR7, which he believed was the
JEDEC equivalent of the Micron/NVIDIA GDDR6X.  He said he didn't think we needed
anything new in terms of a BIRD.  It's just single-ended PAM4.  As soon as you
go differential at the front end, everything looks the same in the .dll.  He
said the threshold parameters are relative to the differential waveform.  It's
not really different than single-ended NRZ AMI modeling.  Fangyi said the
existing DC_Offset parameter definition would apply.

Randy noted that a presentation from Fangyi at the most recent IBIS summit had
talked about non-linearities that can add complexities.  It does have its
challenges, and perhaps improvements in EDA tools, etc., could be applied.

Walter said there are some non-linearities you may want to include, but they can
be handled by Model Specific parameters.  He said the AMI specification for the
input waveform to the Tx is fine.  There may be some non-linearities in the
output levels, but these can be handled in the model.  There are also some rise-
time subtleties in the difference between 0-1, 0-2, or 0-3 transitions, for
example.  These edge rate differences might be measurable with a 50 Ohm
termination, but as soon as you put them through a real lossy channel any edge
timing differences are filtered out.

AMI root name clarification BIRD:
Michael discussed the BIRD draft he had sent out.  He said it is a clarification
BIRD that unambiguously states the relationship between the top-level tree name
in the .ami file and the first string value in the AMI_parameters_in and
AMI_parameters_out contents.

He said that the interpretation of the IBIS 7.1 specification by most EDA tools
is that the first value in AMI_parameters_out must exactly match the root name
in the .ami file.  Some models didn't follow this rule, and EDA tools sometimes
emit confusing error messages.  He noted that he had filed ibischk parser BUG227
for this issue, and it had been deferred until this BIRD is addressed.

Michael noted that Mike LaBonte had provided some suggestions that had not yet
been incorporated.  He said there might be an updated draft coming.  Bob asked
if there were parser implications.  Michael said his interpretation was that the
parser could call the executable model functions and issue a warning if there
is a mismatch between what the model returns and the .ami file root name.  He
acknowledged that this would be a non-trivial upgrade to the parser, as it does
not currently call any of the executable model functions.  He said this was also
part of the justification for him proposing that the [Test Data] data keyword be
expanded to include AMI support.

Agenda email cleanup:
Arpad suggested that Item 9 could be removed.  He said he would move Michael's
AMI root name checking BIRD to its own item.  The other entry in item 9, Update
outstanding BIRDs with new IBIS 7.1 page numbers, had already been completed
and could be removed.  There were no objections to this suggestion.

- Ambrish: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

-------------
Next meeting: 01 February 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
